InfoMagic Standards 1994 January

home *** CD-ROM | disk | FTP | other *** search

/ InfoMagic Standards 1994 January / InfoMagic Standards - January 1994.iso / misc / merit / idrp / idrp_ip.txt < prev next >

Wrap

Text File | 1992-07-20 | 33KB | 991 lines

Network Working Group Susan Hares Request for Comments: DRAFT NSFNET/MERIT Version 3 June 1992 IDRP for IP Status of this memo This memo specifies the adaptation of the ISO Inter-Domain Routing Protocol ([1]) that enables it to be used as an Inter-Autonomous System routing protocol in the TCP/IP Internet. IDRP with this adaptation will be called "IDRP for IP" in this document. Dual IDRP, that is, a single instance of IDRP that can simultaneously support Inter-Domain/Inter-Autonomous System routing in the TCP/IP and OSI Internets is outside the scope of this document. The whole family of IDRP related documents and their functions are listed in [2]. This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." 1. Acknowledgements A large set of thanks to Dave Katz(cisco) who helped edit this help with the document. I would also like to express my thanks to Scott Brim (Cornell University) for his review and constructive comments. 2. Overview IDRP ([1]) is defined as the protocol for exchange of Inter-Domain routing information between routers to support forwarding of ISO 8473 (Connectionless Network Layer Protocol (CLNP))[3] PDUs. This document contains the appropriate adaptation of the IDRP protocol definition that enables it to be used as protocol for the exchange of inter-autonomous system information among routers to support the forwarding of IP packets across multiple autonomous systems. The adaptation is defined is such a way that a Dual IDRP will be Expiration Date December 1992 [Page 1] RFC DRAFT June 1992 able to fully interoperate with IDRP for IP. 3. Assumptions The IDRP for IP protocol assumes that network addresses are globally unique. The IDRP for IP protocol cannot be guaranteed to work in an environment where network addresses are not globally unique. 4. The Adaptation Layer The Inter-Domain Routing Protocol (IDRP) or, more formally, "The Protocol for the Exchange of Inter-Domain Routeing information among Intermediate Systems to support Forwarding of ISO 8473 PDUs (IDRP)" is the inter-domain routing protocol defined to support the forwarding of Connectionless Network Layer Protocol (CLNP) [ISO 8473] packets that traverse multiple routing domains. This ISO protocol does not require participating domains to support any specific ISO Intra-Domain protocol, such as IS-IS (ISO IS 10589)[4], nor does it require participating routers to run ES-IS (ISO 9542)[5]. The only requirements imposed by the protocol on the participating routers is that the protocol information can be exchanged between them over a connectionless network layer, which in the case of OSI is CLNP, and that the network layer connectivity between routers within a single routing domain should be provided by means outside of IDRP (e.g., via some intra-domain routing protocol). IDRP does not place any restrictions on the structure of reachability information, as long it can be expressed as an arbitrary set of variable length address prefixes. Since IP can provide connectionless service between routers, and since reachable IP destinations can be expressed as IP address prefixes, IDRP can be easily adapted to be an Inter-Autonomous system routing protocol which can be used in the pure TCP/IP Internet. IDRP for IP provides a set of mechanisms to support "classless" inter-autonomous system routing. These mechanisms include support for treating IP reachability information as a prefixes of variable length, without any distinction between class A/B/C network addresses. Thus, IDRP for IP is well suited to support the proposed supernetting scheme [8]. This document assumes that the reader is familiar with the following documents: - IP protocol specification (RFC 791)[6], and Expiration Date December 1992 [Page 2] RFC DRAFT June 1992 - IDRP specification (CD/DIS 10747). A few definitions are in order to aid the reader: BIS - a Boundary Intermediate System (or border router) BISPDU - an IDRP message exchanged between a pair of BISs FIB - Forwarding Information Base (IP forwarding table) IS - Intermediate System (router) NET - Network Entity Title - an ISO network address for a router NLRI - Network Layer Reachability Information (set of reachable destinations) NPDU - an IP packet PDU - a packet SNPA - SubNetwork Point of Attachment While conceptually it is possible to define a mapping between the security field of an IP header and IDRP NPDU-derived Distinguishing Attributes, this mapping is outside the scope of this document. In addition, address-specific QoSs (Source Specific QoS and Destination Specific QoS) have no counterparts in IP. Therefore, the use of the following IDRP Distinguishing Attributes for IP packets will not be defined in this document: - Priority - Source Specific QOS - Destination Specific QOS - Source Specific Security - Destination Specific Security Mapping between the following IDRP Distinguishing Attributes: - Transit Delay - Residual Error - Expense - Capacity and the IP Type of Service (TOS) parameters is defined in Section Expiration Date December 1992 [Page 3] RFC DRAFT June 1992 5.2.3. Note that an implementation that does not support any of the NPDU-derived Distinguishing Attributes can fully interoperate with an implementation that does support them. Therefore, an IDRP for IP implementation that will support routing sensitive to the parameters present in the TOS field of the IP header will be compatible with the implementation that does not provide such support. 5. Implementor's Guide for IP specific functions. In order to implement IDRP for IP, only a subset of the features of the IDRP protocol must be implemented. 5.1 Features in IDRP which shall not be implemented The functions of the IDRP protocol which shall not be implemented for IDRP for IP are those functions which deal with the following (all references are with respect to the IDRP document [1]): - Source Specific QOS according to section 8.12.12 - Destination Specific QOS according to section 8.12.13 - Source Specific Security according to section 8.12.16 - Destination Specific Security according to section 8.12.17 - Priority according to section 8.12.19 - Forwarding CLNP packets according to section 9 - The interface to CLNP (ISO 8473) according to section 10 - support of the Network Management information described in the IDRP GDMO according to section 12 Therefore, with IDRP for IP the following items dealing with CLNP in the IDRP conformance clause (section 13.1 of [1]) shall not be implemented: - clause (d): SOURCE SPECIFIC QOS, DESTINATION SPECIFIC QOS, SOURCE SPECIFIC SECURITY, DESTINATION SPECIFIC SECURITY, PRIORITY - clause (r) - clause (s) Expiration Date December 1992 [Page 4] RFC DRAFT June 1992 - clause (t) 5.1.1 PICS Table Information The PICS (Protocol Implementation Conformance Statement) provides a convenient and concise mechanism to define which function need and need not be implemented for IDRP for IP. All references in this section are with respect to [1]. All items with PICS Status as Optional need not be implemented in IDRP for IP. Specifically, IDRP for IP does not require (and, indeed, does not need) support for the following items in A.4.10 Table 16: TDLY, RERR, EXP, SQOS, DQOS, SSEC, DSEC, CAPY, PRTY, in A.4.10 Table 17: TDLYP, RERRP, EXPP, SQOSP, DQOSP, SSECP, DSECP, CAPYP, PRTYP, in A.4.8 Table 14 (IDRP CLNS Forwarding), and BISMGT in A.4.3 Table 9 (ISO Network Management support). Implementation of all other items with Optional Status not listed in the previous paragraph is optional. 5.2 Features in IDRP which shall be implemented An implementation of IDRP for IP shall contain all mandatory features of IDRP, except those mentioned in Section 5.1. In addition, a BIS for IDRP for IP shall implement: 1.) an interface to the IP protocol described in section 5.2.1 of this document 2.) the ability to identify and extract IP reachability and IP forwarding information as described in section 5.2.2 of this document 3.) IP packet forwarding functions described in section 5.2.4 of this document 4.) domain configuration information listed in section 5.2.6 of this document 5.) the advertisement of IP address information in NLRI as described in section 4.3 of this document 4.2.1 Exchanging IDRP information between IP-only routers. IDRP assumes pair-wise communication between participating BISs. IDRP information is carried between a pair of BISs in the form of BISPDUs. In the case of IDRP for IP, these BISPDUs are carried in Expiration Date December 1992 [Page 5] RFC DRAFT June 1992 the data field of IP packets of protocol type X. 4.2.2 Identifying IP reachability and IP forwarding information NLRI passed by the UPDATE PDU has an indication of protocol type. An implementation of IDRP for IP shall have the following values in the NLRI field: Proto_Type: 1 (ISO/IEC TR 9577 IPI/SPI) Proto_Length: 1 Protocol: x'CC' Addr_Length: variable Addr_Info: IP address prefixes, encoded in binary An implementation of IDRP for IP shall ignore any NLRI indicating a different protocol type. The NEXT_HOP attribute in the UPDATE PDU also has a Type field which indicates the protocol family for the address of the NEXT_HOP. An implementation of IDRP for IP shall have the following values in the NEXT_HOP field: Proto_Type: 1 (ISO/IEC TR 9577 IPI/SPI) Proto_Length: 1 Protocol: x'CC' Length of NET: 4 NET of Next Hop: an IP address, encoded in binary SNPA information: as appropriate for the subnetwork type in use An implementation of IDRP for IP shall ignore any NEXT_HOP information indicating a different protocol type. 4.2.3 Mapping between IP Type Of Service parameters and IDRP Distinguishing Attributes. IDRP for IP supports the following distinguishing attributes: - Transit Delay - Residual Error - Expense Expiration Date December 1992 [Page 6] RFC DRAFT June 1992 - Capacity A conformant implementation is required to recognize these attributes when received from an adjacent BIS. IP defines four distinct Type of Service Parameters (see [X]): - minimize delay - maximize throughput - maximize reliability - minimize monetary cost An IP packet can carry at most one of the above ToSs. Therefore, a RIB in IDRP can have at most one distinguishing attribute. An IP-derived distinguishing attribute is defined as the ToS parameter extracted from an IP packet that needs to be forwarded by a BIS. If the value of the MBZ bit (bit 7) of the Type of Service octet in the IP header is 1, then the IP-derived distinguishing attribute is mapped into the "default" RIB-Att (RIB with no distinguishing attributes). Otherwise, the mapping between the IP-derived distinguishing attribute and a RIB-Att is defined as follows: IP ToS IDRP Distinguishing Attribute --- --- ----------------------------- minimize delay Transit Delay maximize throughput Capacity maximize reliability Residual Error minimize monetary cost Expense 5.2.4 Forwarding of IP packets This section is intended to define the same function for IP packets as is defined for CLNP packets in the "Forwarding Process for CLNS" (Section 9 in [1]). It is assumed that a BIS is capable of distinguishing between a FIB constructed by means of an intra-autonomous system routing protocol and a FIB constructed by means of IDRP. After a BIS determines the packet's destination IP address, the BIS Expiration Date December 1992 [Page 7] RFC DRAFT June 1992 shall proceed as follows: a.) If the destination address depicts a system located within the autonomous system of the receiving BIS, then the BIS shall forward the IP packet to any of the ISs listed in the managed object INTRA-IS. That is, any further forwarding of the IP packet is the responsibility of the intra-autonomous system routing protocol; otherwise, b.) the destination system is located in a different autonomous system, and the local BIS shall perform the following actions: It shall determine the IP-Derived Distinguishing Attribute, according to clause 5.2.3. It shall next apply the procedures of clause 5.2.3 to determine if the IP-Derived Distinguishing Attribute matches any of the RIB-Atts of the information base(s) supported by the local BIS. If such a match is found, then the FIB with the matched RIB-Atts is used for forwarding. If the procedures of clause 5.2.3 identify a non-default IP- Derived Distinguishing Attribute, but the local BIS does not maintain a FIB with the matching RIB-Atts, or the local BIS maintains a FIB with the matching RIB-Atts but this FIB does not have a route to the destination, then the local system sets the MBZ bit (the 7th bit) of the Type Of Service field in the IP packet to 1 and uses FIB with no distinguishing attributes. The incoming IP packet shall be forwarded based on the FIB entry that has the longest IP address prefix that matches the destination of the incoming IP packet, as follows: 1.) If the entry in the inter-domain FIB that corresponds to the destination address of an incoming IP packet contains a NEXT_HOP that identifies an interface of a BIS such that the interface is attached to a subnet shared with the local BIS, then the IP packet shall be forwarded directly to the BIS indicated in the NEXT_HOP entry over that interface; otherwise, 2.) if the entry in the inter-domain FIB that corresponds to the destination address of the incoming IP packet contains a NEXT_HOP entry that identifies an interface of a BIS such that the interface is not attached to any of the subnets attached to the local BIS, then the local BIS has the following options: a.) Encapsulate the IP packet The local BIS may encapsulate the IP packet, using its own IP address as the source address and the IP address of the next-hop BIS contained in the NEXT_HOP Expiration Date December 1992 [Page 8] RFC DRAFT June 1992 entry as the destination address. b.) Use paths calculated by the intra-autonomous system routing protocols The local BIS may query the FIB constructed by the intra-autonomous system routing protocols to ascertain if that FIB contains a route to the destination system. If that is the case, and if the path constructed by the intra-autonomous system routing protocols delivers the IP packet to the appropriate next-hop BIS, then the IP packet may be forwarded using the FIB constructed by the intra-autonomous system routing protocols. Table 1) PICS Proforma for IDRP: IP packet forwarding ITEM Questions/Features Refer. Status Support ---------------------------------------------------------------- IP_EXTFWD Does the BIS correctly forward 5.3 M Yes___ IP packets with destinations outside its routing domain? IP_INTFWD Does the BIS correctly forward 5.3 M Yes___ IP packets with destinations inside its routing domain? The "ITEM" column describes the feature in the IP forwarding function that the IDRP implementation is to provide. The "Question/Feature" section seeks to describe the feature. The Reference is the section in this document that describes this feature. The status gives an indication of "M" - Mandatory feature for an IDRP implementation or "O" - optional feature. The "Support" column is a column for the implementor to check whether this feature is available in a particular implementation.) Expiration Date December 1992 [Page 9] RFC DRAFT June 1992 5.2.5 Confederations of Autonomous Systems. IDRP supports the ability to group Routing Domains into a Routing Domain Confederation. Likewise, IDRP for IP supports the ability to group a collection of autonomous systems into a Confederation of autonomous systems. With respect to the IDRP document in the context of IDRP for IP, the terms "Routing Domain Confederation" and "Confederation of autonomous systems" should be treated as synonymous. 5.2.6 Domain Configuration Information Correct Operation of IDRP described in [1] assumes that a minimum amount of information is available to both the inter-domain and intra-domain routing protocols. This information is static in nature, and is not expected to change frequently. The specific format of this information is defined in the RFC IDRP MIB document [7]. The information required by a BIS that implements the IDRP for IP protocol is: a.) Location and identity of adjacent Intra-Domain ISs (routers) The MIB table INTRA-IS lists the IP addresses of the routers to which the local BIS may deliver an inbound NPDU whose destination lies within the BIS's routing domain. These routers listed in the Intra-IS table support the intra-domain routing protocol of this autonomous system, and share at least one common subnet with the BIS. In particular, if the local BIS participates in both the inter-domain routing protocol (IDRP) and the intra-domain routing protocol, then the IP address of the local BIS will be listed in the INTRA- IS table. b.) Location and identity of BISs in the BIS's domain This information permits a BIS to identify all other BISs located within its routing domain. This information is contained in the MIB table INTERNAL-BIS, which contains a set of IP addresses which identify the BISs in the domain. c.) Location and identity of BISs in adjacent domains: Each BIS needs information to identify the IP address of each BIS located in an adjacent RD and reachable via a single subnetwork hop. This information is contained in the IDRP MIB table EXTERNAL-BIS-NEIGHBORS, which is a table of IP addresses. Expiration Date December 1992 [Page 10] RFC DRAFT June 1992 d.) IP network address information for all systems in the routing domain This information is used by the BIS to construct its network layer reachability information. This information is contained in the MIB table INTERNAL-SYSTEMS. The IP network address information can include: - host addresses, - Network and subnet mask sequences, or - Supernetting network sequences. Please refer the IDRP MIB specification for the specific details of the INTERNAL-SYSTEMS table. The IDRP for IP protocol provides support for the Supernetting approach described in [8] for the assignment and aggregation of IP network reachability information. The IDRP for IP Usage document [9] provides details on how to: - carry IP information in the IDRP NLRI, and - use the Supernetting approach to aggregate IP network reachability information. e.) LOCAL RDI This information is contained in managed object LOCAL-RDI; it is the RDI of the routing domain in which the BIS is located. As specified in section 8 of this document, the RDI for an IDRP for IP routing domain has an NSAP Address format. This NSAP Address format is built out of a fixed "header" and the autonomous system number of this autonomous system (routing domain). f.) RIB-AttSet The RIB-AttSet contains information about the QoS functions a BIS will support. As described in section 3, this can be none, any, or all of the Transit Delay, Residual Error, Expense, and Capacity distinguishing attributes. g.) RDC-Config: This information identifies all the routing domain confederations (RDCs) to which the RD of the local BIS belongs, and it describes the nesting relationships that are in force between them. It is contained in the MIB table RDC-Config. Expiration Date December 1992 [Page 11] RFC DRAFT June 1992 Each RDC is identified by an RDI which has the format described in section 8 of this document. h.) Local SNPAs The LOCAL SNPA MIB table contains a list of SNPAs (Subnetwork Points of Attachment, i.e. subnetwork addresses) per IP address of the BIS. 5.3 Advertising NLRI information for IP addresses The NLRI field in an UPDATE PDU contains IP address information about systems that reside within a given routing domain or whose IP address space is under the control of the administrator of the routing domain. It should not be used to convey information about the operational status of these systems. The information in the NLRI field is intended to convey static administrative information rather than dynamic transient information; for example, it is not necessary to report that a given system has changed from offline to online. End systems (hosts) and Intermediate systems (routers) within a RD using IDRP may use any IP address that is valid within the IP context. Within the NLRI, the address information for a set of IP addresses may be represented by an IP prefix. An IP prefix is the sequence of bits in a 4 byte IP address which are common between a set of IP addresses. For example, the addresses 192.5.0.0 through 192.5.255.255 have the first 16 bits of the address information in common. These 16 bits of the IP address may be called an IP prefix which represents the set of IP addresses 192.5.0.0 through 192.5.255.255. An IP prefix must contain a contiguous set of bits starting at the most significant bit, but the bits may cover any part of the 4 byte IP address. The following guidelines for inclusion of IP address prefixes in the NLRI field of the UPDATE PDUs originated within a routing domain will provide efficient use of this protocol: a.) Only IP prefixes representing IP addresses that are within the control of the Administrator of a given routing domain may be reported in the NLRI field for a RD. These IP prefixes can represent IP addresses for systems which are: - online, - offline, or - allocated to the network, but not yet allocated to a machine. Expiration Date December 1992 [Page 12] RFC DRAFT June 1992 b.) IP prefixes representing IP addresses outside of the RD administrator's control shall not be included in the NLRI. c.) For efficient use of the protocol, the WITHDRAW ROUTES field should not be used to report the NLRI of systems that are offline. This field should be used only to advertise IP prefixes for IP addresses that are no longer under the control of the administrator of the local routing domain, regardless of whether the systems are online or offline. A conformant implementation is required to have the ability to specify when an aggregated route may be generated out of partial routing information. A BIS at the border of an autonomous system (or group of autonomous systems) must be able to generate an aggregated route for a whole set of NLRIs over which is has administrative control, even when not all of them are reachable at the same time. 6 Determining the forwarding address (Next Hop) NEXT_HOP information shall be derived from the NEXT_HOP attribute in the UPDATE BISPDU. If that attribute is not present, it shall be derived from the source IP address of the IP packet that carries the UPDATE BISPDU. 7 Routing Domain Identifiers used for both IP and OSI Routing Domain Identifiers (RDIs) are identifiers used in BISPDUs to uniquely identify individual routing domains and routing domain confederations. For ease of administration, the RDI is taken out of the NSAP address space. However, the RDI is just a number which identifies the routing domain, and need not bear any relationship to any reachable addresses within the domain. For ease of interworking with other IP inter-autonomous system routing protocols, The RDI used for an autonomous system running IDRP for IP should be derived from an appropriately assigned Autonomous System Number as follows: xx.xx.xx.xx.aa.aa Where xx.xx.xx.xx is a unique prefix assigned by a valid addressing authority (TO BE DETERMINED), and aa:aa is the autonomous system nummber. Expiration Date December 1992 [Page 13] RFC DRAFT June 1992 This encoding of the RDI contains a "fixed header" (the xx.xx.xx.xx sequence) plus the AS value. (Note: While AS values are currently 2 octets long, IDRP allows Routing Domain Identifiers to be of arbitrary length. Thus, if the space of AS numbers is expanded to be greater than two octets, this may be accommodated by simply lengthening the above encoding--the AS number following the fixed header is considered to be right justified, and its size can be unambiguously determined from the RDI length.) 8 Deployment Guidelines for IDRP for IP The correct and efficient operation of the IDRP protocol requires that certain guidelines are used for deployment with ISO routing Domains. Some equivalent deployment guidelines for IDRP for IP are required within Autonomous Systems. These guidelines represent only the required deployment guidelines, and not details on the usage of IDRP for IP in the Internet. The details of the Usage of IDRP for IP are contained in [9]. 8.1 Minimum configuration of an Autonomous System An autonomous system using IDRP for IP must as a minimum contain: - one BIS, and - one BIS capable of delivering NPDUs to the intra-domain routing function if the AS contains hosts. 8.2 Multiple IDRP sessions between the same pair of routers An IP router may have multiple IP addresses, one for each interface. In contrast, an OSI Intermediate System has only one Network Entity Title (network address). An OSI BIS thus may not have multiple IDRP sessions with another BIS, since the NET is unique and there is no mechanism for multiplexing sessions. However, an IP router may potentially have multiple IDRP sessions with another router, since each BIS may have multiple IP addresses, and one BIS may not be able to ascertain that those addresses correspond to the same BIS. Multiple IDRP sessions between IP BISs may not be efficient, but they are not illegal, nor do they impact the robustness of the IDRP for IP protocol; they will simply appear as multiple paths to the same neighboring AS. One possible way of avoiding multiple parallel IDRP sessions between a pair of BISs within a single autonomous system is to bind all source addresses of outgoing BISPDUs to the IP address of a particular interface of Expiration Date December 1992 [Page 14] RFC DRAFT June 1992 the BIS. Likewise, for a pair of BISs located in adjacent autonomous systems, binding the source addresses to a single address of an interface attached to a common subnetwork allows for the elimination of multiple parallel sessions. 9. References [1] ISO/IEC DIS 10747 - Information Processing Systems - Telecommunications and Information Exchange between Systems - Protocol for Exchange of Inter-domain Routeing Information among Intermediate Systems to Support Forwarding of ISO 8473 PDUs, 1992. [2] RFC xxx - (Sue Hares) IDRP Document Family Tree [3] ISO 8473 - Information Processing Systems - Data Communications - Protocol for Providing the Connectionless-mode Network Service, 1988. [4] ISO/IEC 10589 - Information Processing Systems - Telecommunications and Information Exchange between systems - Intermediate System to Intermediate System Intra-Domain routeing information exchange protocol for use in conjunction with the Protocol for providing the Connectionless-mode Network Service (ISO 8473), 1992. [5] ISO 9542 - Information Processing Systems - Telecommunications and information exchange between systems - End system to Intermediate system routeing exchange protocol for use in conjunction with the Protocol for providing the connectionless-mode network service (ISO 8473) [6] RFC 791 (Jon Postel, editor) - Internet Protocol - DARPA Internet Program Protocol Specification (September 1981) [7] RFC xxx (Susan Hares) - IDRP MIB [8] Fuller, V., Li, T., Yu, J, and Varadhan, K., "Supernetting: an Address Assignment and Aggregation Strategy", Internet Draft, April 1992 [9] RFC xxx (Susan Hares) - Usage of IDRP for IP Expiration Date December 1992 [Page 15]